reset disabled session per SessionSchedule to avoid message loss on Logon#1181
Merged
chrjohn merged 6 commits intoquickfix-j:masterfrom May 6, 2026
Merged
Conversation
chrjohn
changed the title
SessionSchedule to avoid message loss
Contributor
Author
|
Any adjustments to make, happy to help. |
Member
|
Not at the moment, slowly working through my backlog. ;) thank you |
chrjohn
reviewed
May 2, 2026
Co-authored-by: Christoph John <christoph.john@macd.com>
Member
|
@Ra9huvansh |
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a QuickFIX/J session lifecycle edge case where disabled (logged-out) sessions could skip SessionSchedule-driven resets, leading to queued messages/sequence number drift and potential message loss on the next reconnect.
Changes:
- Adjusts
Session.next()control flow so theSessionSchedulecheck can run even when the session is disabled and not logged on. - Adds a regression test covering the disabled + disconnected + advanced sequence numbers scenario to ensure scheduled resets still occur.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
quickfixj-core/src/main/java/quickfix/Session.java |
Moves the disabled+not-logged-on early-return to after the schedule block so scheduled resets can still happen. |
quickfixj-core/src/test/java/quickfix/SessionTest.java |
Adds testDisabledSessionIsResetBySchedule() to reproduce/guard the reported message-loss scenario (issue #965). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
chrjohn
changed the title
SessionSchedule to avoid message lossSessionSchedule to avoid message loss on Logn
chrjohn
changed the title
SessionSchedule to avoid message loss on LognSessionSchedule to avoid message loss on Logon
chrjohn
reviewed
May 4, 2026
chrjohn
reviewed
May 5, 2026
chrjohn
reviewed
May 6, 2026
changed comment
Member
|
@Ra9huvansh thank you 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #965
When a session is disabled (e.g. after calling logout()) and has no active connection, Session.next() was returning early before it could reach the SessionSchedule check. This meant that even if the session schedule said it was time to reset, the reset never happened.
The problem shows up when messages are sent via sendToTarget() to a disabled session. They get queued in the message store and advance the sequence numbers. When next() is called by the internal timer, it hits the early return and exits without resetting, so those queued messages are never cleared. The next time the session connects, method next() is called by the timer thread within a second, resetting the message store and losing the stored messages.
The fix is straightforward. Instead of returning immediately when the session is disabled and not logged on, we now let execution fall through to the session schedule block first, and return after it. The existing state.isResetNeeded() check already handles @philipwhiuk's suggestion of only resetting when sequence numbers have actually advanced beyond 1, so no extra logic was needed there.
Changes:
Tests run: